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SMTP 521 and 556 Reply Codes 


Abstract 


This memo defines two Simple Mail Transfer Protocol (SMTP) reply 
codes, 521 and 556. The 521 code was originally described in an 
Experimental RFC in 1995 and is in wide use, but has not previously 
been formally incorporated into SMTP. The 556 code was created to 
support the new tests and actions specified in RFC 7505. These codes 
are used to indicate that an Internet host does not accept incoming 
mail at all. This specification is not applicable when the host 
sometimes accepts mail but may reject particular messages, or even 
all messages, under specific circumstances. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7504. 
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This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
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include Simplified BSD License text as described in Section 4.e of 
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Introduction 


The SMTP specification [2] (referred to, along with its various 
updates, as "SMTP" below) contains a list and discussion of reply 
codes. This document updates that list with a new code, 521, for use 
in response to an initial connection. In that context, it 
specifically denotes a system that does not receive mail or otherwise 
handle SMTP mail or inquiry transactions. That code differs from the 
use of reply code 554, recommended by RFC 5321, because the latter 
code can be used in a larger variety of situations, including mail 
that is not accepted for, or from, particular sources, destinations, 
or addresses. It also introduces a second reply code, 556, for use 
when an SMTP client encounters a domain in a forward-pointing address 
that it can determine (e.g., from the DNS "null MX" convention [5]) 
does not support receipt of mail and has to report that condition to 
a host that delivered the message to it for further processing. 


This specification updates RFC 5321 to add the new codes. The 521 
code was first formally proposed in the Experimental RFC 1846 [4]; 
this document updates that specification to standardize the code and 
provide more specific treatment of it. 


1. Terminology 


The reader of this document is expected to have reasonable 
familiarity with the SMTP specification in RFC 5321, particularly its 
discussion of reply codes and their use and theory. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [1]. 


Background 
Many Internet hosts are not in a position -- whether technically, 
operationally, or administratively -- to offer mail service. If an 


SMTP client (sender) attempts to open a mail connection to a system 
that does not have an SMTP server, the connection attempt will time 
out. SMTP requires that timeouts result in the client queuing the 
message and retrying it for an extended period. That behavior will 
result in wasted resources and long delays in getting an error 
message back to its originator. 


One alternative is to run a dummy SMTP server on hosts that do not 
receive mail under any circumstances and have that dummy server 
return a fatal error reply code in response to any connection-opening 
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attempt. Another is to determine, from a separate source such as a 
DNS record, that the host does not receive mail. This document 
specifies reply codes to be used for those purposes. 


3. The 521 Reply Code 


This specification adds the 521 reply code to the repertoire 
specified in SMTP, reserving it for use at connection-opening time to 
indicate that the host does not accept mail under any circumstances. 
It SHOULD be used for dummy SMTP servers whose sole purpose is to 
notify systems that attempt to open mail connections that the host 
never accepts mail. It MAY be used in other situations where the 
intent is to indicate that the host never accepts mail. It SHOULD 
NOT be used for situations in which the server rejects mail from 
particular hosts or addresses or in which mail for a particular 
destination host is not accepted. As discussed in SMTP, reply code 
554 is more appropriate for most of those conditions; an additional 
case, in which the determination that mail is not accepted is 
determined outside the mail system, is covered in the next section 
(Section 4). 


"Server does not accept mail" (or a variant such as "Host", "Domain", 
or a related term) is an acceptable message to accompany a 521 code 
used for this purpose. 


Once the 521 reply code is returned instead of the usual 220, the 
SMTP session proceeds normally. If the SMTP client attempts to send 
additional commands other than QUIT, the server MAY either continue 
sending 521 reply codes or simply close the connection. If the 
purpose of running a dummy SMTP server that returns a 521 code is to 
conserve resources, the latter will usually be preferable. 


4. The 556 Reply Code 


This specification adds the 556 reply code to the repertoire 
specified in SMTP. When an intermediate SMTP system (typically a 
relay) that would normally attempt to open a mail connection to a 
host referred to in a forward-pointing address can determine that the 
host does not accept mail connections, and do so without attempting 
to open a connection to that target host, it is appropriate for it to 
return a reply with a 556 code to the system that sent it the message 
for outbound transmission. Interpretation of a special DNS record, 
found when a lookup is performed in conjunction with a RCPT command 
[5], is one such method (and the only standardized one at the time 
this specification was written). 
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When an SMTP server returns a 556 reply code after receiving a 
command (such as RCPT, which contains a forward-pointing address) 
because it has information (such as discussed above) that the mail 
will not be accepted, the SMTP client is expected to handle the 
response like any other permanent negative completion reply to the 
command. This is consistent with the SMTP specification. 


Small Details to Avoid Loose Ends 
1. Specific Changes to RFC 5321 


This document adds the 521 code, with message "Host does not accept 
mail", and the 556 code, with message "Domain does not accept mail", 
to the function group and numerical lists (Sections 4.2.2 and 4.2.3, 
respectively) of RFC 5321. It also adds the 521 code to the 
"CONNECTION ESTABLISHMENT" portion of Section 4.3.2 ("Command-Reply 
Sequences"), preceding the 554 code, and the 556 code to the "RCPT" 
portion of that same section. 


-2. The RFC 1846 Experiment 


By formalizing reply code 521, this specification ends the experiment 
proposed in RFC 1846. That document also discusses general 
strategies for hosts that do not accept mail directly. That 
discussion is out of scope for the present document. 


IANA Considerations 


This document updates RFC 5321 to add descriptions and text for two 
reply codes, but there is no registry for those codes. IANA has 
updated the "Enumerated Status Codes" subregistry of the "Simple Mail 
Transfer Protocol (SMTP) Enhanced Status Codes Registry" [3] to 
include these codes, specifically: 


o Added 521 to the list of codes associated with the enhanced code 
entry for X.3.2, which now references this document. 


o Added this document to the references associated with the enhanced 
code entry for X.1.10 and reply code 556. Note that, if a use for 
556 arises that is not associated with null MX [5], it may be 
necessary to add an additional enhanced code, but such action is 
outside the scope of this document. 
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7. Security Considerations 


Not running any SMTP server, or running an SMTP server that simply 
emits fixed strings in response to incoming connections, should 
provide significantly fewer opportunities for security problems than 
running a complete SMTP implementation. See the Security 
Considerations section of RFC 7505 [5] for a discussion of security 
issues with that approach. Use of the specific codes provided here 
provides more information to the client than a generic or arbitrarily 
chosen 5yz code but should have no other effect on security. 
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